Subject: Request for approval

From: "Ralph Case" <[email-masked]>
Date: Mon, 10 Jul 95 09:49:16 EDT

As mentioned at the SIG meeting at AIW7 (and in the minutes of
that meeting), the changes to generalize the usage of the ODAI
are documented and available as noted below.  I would like to
formally request SIG approval of these changes.

Please review and post any comments by July 25.

SNA Formats
   These changes are located in file arch8128f.psbin.
APPN Architecture Reference
   NOF chapter: These changes are located in file archno8128.psbin.
   CS chapter: These changes are located in file archcs8128.psbin.
   ASM: These changes are located in file archam8128.psbin.
        Note: The ASM chapter changes marked by the vertical stroke
        are for this item.  Additional changes of an editorial nature
        are marked by the "greater than" (>) sign; these merely clarify
        LFSID usage and are not a technical change to the architecture.
   PC: These changes are in file archpc8128.psbin.
   Appendix A: These changes are in file archbo8128.psbin.

Ralph Case                    [email-masked]    (919)254-1882
APPN/APPC Architecture
IBM Networking Hardware Division

---

From: Dave Finnie <[email-masked]>
Date: Fri, 14 Jul 1995 15:45:10 +1000

Ralph,

I agree with Jim's comment - that page doesn't seem to belong.

On page 6-10 & 6-11, I am a little confused by the use of dependent
SLU. It's true that in general I think this term is used when what is
really meant is non-APPC. In the SSE environment, is the SLU actually
dependent ? Does it have an SSCP-LU session ? I don't think it does in
this evironment.

If my assumptions are correct, then I think the reference to SSE
should be removed. Since our product's first release (before SSE came
into being), we have supported receipt of non-APPC BIND rq using
*independent* LU addressing (ie dynamic LFSID assignment). I think
this is the scenario that is being described on 6-11. However, we do
not support SSE.

Dave

---

From: Dave Finnie <[email-masked]>
Date: Wed, 19 Jul 1995 08:54:26 +1000

Ralph,

As an additional comment to the Generalised ODAI Usage:

On page 6-30 it discusses the cheds that ASM performs on LFSID usage
in received BIND rqs.

It discusses that ASM will reject a BIND rq received if the ODAI value
is its own (ie remote LS assigning an LFSID in the local LS' address
space).

It draws special attention to the case of receiving a dependent LU-LU
BIND rq, and that it must perform a special check because ODAI is
reserved in this case. I have three issues with this discussion:

 * Note states that it is a dependent LU BIND rq if LFSID=X'01'. I
   think this should be SIDH=X'01'.

 * ODAI is not reserved if both LSs support Generalised ODAI usage.

 * I don't think any special checks need to be made. Since we have now
   explicitly stated the unwritten requirement that BF must be primary
   LS unless Generalised ODAI usage is supported by both LSs, then
   ODAI will *always* be 0 (ie the reserved value) since BF will
   always be primary LS *and* primary for the session.

So I think perhaps the text beginning:

  "The exception to this rule..." (to the end of the paragraph)

be replaced with:

  "Note that in the case where the local node supports dependent LU-LU
   sessions on the TG, this TG does not support Generalised ODAI
   Usage and the BIND's SIDH=X'01', the BIND is for a dependent LU
   session. No special checks need to be made for this case, since,
   even though ODAI is reserved (set to zero by the sender), it would
   normally be set to zero since the BF must be primary on the link and
   primary in the session."

Having a special case makes the whole addressing issue appear more
complex than it actually is.

Clearly if the sender sets ODAI to 1 in this case, it is in error, and
addressing problems will occur, so the problem should be identified
immediately.

Dave